\section{Creation du modele : M1}
	
	  \subsection{Instanciation du méta-modèle (M2)}
		Le modèle présenté ci-après est une instanciation du modèle précédent, en se basant sur l'architecture 			 			client-serveur, dont voici la représentation schématique : \\
			\begin{center}
				\includegraphics[width=0.5\linewidth]{clientServeurSchema.jpg}
			\end{center}
  Configuration du serveur :\\
			\begin{center}
				\includegraphics[width=0.5\linewidth]{clientServeurSchema_2.jpg}
			\end{center}
		  Nous allons ici, pour une meilleure compréhension, présenter un à un les différents packages composants le diagramme de 		classe. Ces packages sont donc les suivants :\\
			\begin{itemize}
				\item{Le client}
				\item{Le serveur}
				\item{Le connecteur RPC}
			\end{itemize}		
\clearpage	
      \subsection{Le diagramme de classes}

		\paragraph{\textbf{Package : le client :}}
			\begin{center}
				\includegraphics[width=0.6\linewidth]{client.png}
			\end{center}
			\subparagraph{\textit{Description explicative : \\}}
			Client possède deux Config et deux propriétés, fonctionnelles et non-fonctionnelles, héritant de Property.\\
			Les deux configurations sont des agrégats du composant client, puisqu'elles pourront toujours être utilisées par un 			autre composant, si Client n'existe plus.\\
			Client possède des ports typés asynchrones, puisqu'un client enverra ses messages au serveur, sans que la réponse de 				celui-ci soit bloquante.
\clearpage
		\paragraph{\textbf{Package : le serveur :}}
			\begin{center}
				\includegraphics[width=1.00\linewidth]{serveur.png}
			\end{center}
			\subparagraph{\textit{Description explicative : }}
			Le composant Server a comme agrégat sa configuration, de la même manière que les deux config. du composant Client 				vues précédemment.\\		
			La configuration du serveur est un composite, puisqu'il s'agit d'un composant composé de composants. Ces derniers 	 				sont les suivants :
				\begin{itemize}
					\item{ConnectionManager : permet de gérer les connexions au serveur}
					\item{SecurityManager : gère notamment l'authentification des clients}
					\item{DataBase : gère les accès à une base de données\\}
				\end{itemize}
			Pour la communication entre ces composants, comme il s'agit d'une communication bidirectionnelle, chacun possède deux 				ports fournis, et deux ports requis. Ce qui amène aussi à doubler les rôles requis et fournis entre les divers 				connecteurs. Les liens entre composants, via des connecteurs, sont nommés attachments.\\	
			Un binding est présent, entre le port de ConnectionManager, et le port de la config elle-même : ceci permet à chaque 				client de se connecter au serveur, en faisant appel au composant interne de celui-ci (I.e., composant de sa 			configuration.)

		\paragraph{\textbf{Package : le connecteur RPC :}}
			\begin{center}
				\includegraphics[width=0.8\linewidth]{connecteurRPC.png}
			\end{center}
			\subparagraph{\textit{Description explicative : }}
			Le connecteur RPC (Remote Protocol) permet donc d'établir une communication, au travers des rôles fournis et requis, 				entre le serveur et le client, via leur port fournis et requis. Ainsi, un rôle requis sera connecté à un port fourni 				(I.e., un port utilisé par un service fournis.), et un rôle fournis sera connecté à un port requis (I.e., un port 				utilisé par un service requis.).
\clearpage
		\paragraph{\textbf{Package : le diagramme de classes final (Agglomérat des packages) :\\}}
			\begin{center}
				\includegraphics[width=0.80\linewidth]{M1.png}
			\end{center}

\clearpage      
      \subsection{Illustration du modèle client-serveur avec l'exemple de l'ADL ACME}
		\begin{lstlisting}		
			System Client_Serveur = {
				Component Client = {
									port SendRequest;
									Properties{
												requestRate : float = 17.0;
												SourCode : externalFile = "Code-Libe/client.c";
											   }
									}
				Component Serveur = {
									port ReceiveRequest;
									Representation ServerDetails = {
										System ServerDetails = {
											Component ConnectionManager = {
												Ports{ExternalSocket;SecurityCheckIntf;DbQueryIntf}
											}
											Component SecurityManager = {
												Ports{SecurityAnthorization;CredentialQuery;}
											}
											Component Database = {
												Ports{SecurityManagementIntf;QueryIntf;}
											}
											Connector SqlQuery = {
													Roles{caller;callee;}
											}
											Connector ClearanceRequest = {
													Roles{requestor;grantor}
											}
											Connector SecurityQuery = {
													Roles{SecurityManager;Requestor}
											}
											Attachments{
												ConnectionManager.SecurityCheckIntf to 		 	 		
														ClearanceRequest.Requestor;
												SecurityManager.SecurityAuthorization to
														ClearanceRequest.Grantor;
												ConnectionManager.DbQueryIntf to
														SqlQuery.caller;			
												Database.QueryIntf to SqlQuery.callee;
												SecurityManager.CredentialQuery to
														SecurityQuery.SecurityManager;
												Database.SecurityManagementIntf to
														SecurityQuery.Requestor;
											}
										}
										Bindings{
											ConnectionManager.ExternalSocket to
														Server.ReceiveRequest ;
										}
									}
								}
			Connector RPC = {
				Roles{Caller;Callee}
			}
			Attachments:{
				Client.SendRequest to RPC.Caller;
				Server.ReceiveRequest to RPC.Callee;}
			}
		}
	\end{lstlisting}
	Il est cependant bon de noter qu'au sein d'ACME, il y a quelques points de divergences avec notre modèle M1 :
	\begin{itemize}
		\item{Il n'y a pas de différenciation entre propriétés fonctionnelles et non-fonctionnelles}
		\item{Le concept de Représentation vient s'intercaler entre un composant et la config, i.e. un composant contient une 			représentation, contenant X config.}
		\item{Le mot Config est remplacé par System}
	\end{itemize}

